Vercel Usage의 함정

Frontend Cloud Platform 이사다니기

• 현재 회사에서 맨 처음에 웹 클라이언트 배포는 우선 Amplify,ECS로 진행했었다. 그때 당시의 Amplify의 선택 이유는 배포 과정에 있어서 크게 신경써줄게 많이 없다는 편리함이 현재 빠르게 개발하면서 제품에 집중해야하는 시기에 적절하기도 했었고 개인적으로도 사용해봤기 떄문에 따로 학습없이 바로 사용할 수 있었던 부분이 큰 이유였었다.

• 이후에 Amplify를 쭉 사용하다가 올해 초에 Vercel로 이사를 가게 되었었는데 그 이유는 우선 Amplify의 빌드타임이 생각보다 굉장히 오래걸린다는 문제가 있었고 Cloudwatch를 통한 모니터링이 가능하지만 보기 불편하다는 점도 이유중 하나였었다. 물론 에러 모니터링은 Sentry를 사용하고 있긴하지만 실시간으로 모니터링을 해야하는 부분도 있기 때문에 이러한 점들에 있어서 Vercel로 이사가기를 선택했었다.

• 현재 서비스중 2개가 Next.js로 되어있는데 역시 Vercel에서 만든 프레임워크라 그런지 Vercel을 메인 vendor로 사용했을때 빌드/배포 속도가 거의 4~5배 정도가 차이가났다. 초기에는 역시 이사가기를 잘했다는 생각과 앞으로 사용하기도 더 편하고 모니터링부터 여러가지 이점을 가져갈 수 있겠다는 생각이 들었었다.

• Vercel이 문제가 되었던 시점은 서비스에 유저들의 트래픽이 점점 커가기 시작한 시점부터 사용량이 급격하게 증가하는 문제가 있었다. 현재는 vercel pro plan을 사용해서 서비스를 하고있는데 사용량이 최대 1TB까지이고 이 이후부터는 과금이 되는 형태인데 이게 거의 800GB 정도가까이 쓰다보니 월에 360달러 정도의 추가 과금이 발생하는 문제가 생겼다.

• 이건 다른 얘기이지만... vercel은 팀원 1명당 돈을 추가로 받는다.. 생각보다 싼 가격도 아니기도 하다..ㅎㅎ

사용량에 대한 구체적인 문제점

• 구체적으로 사용량이 많이 증가한 이유중 제일 큰 이유가 HLS(Http Live Streaming)방식의 미디어 서비스들을 유저들에게 제공하는데 해당 방식으로 집계되는 Http통신들이 모두 사용량에 잡히면서 사용량이 급격히 증가했었다. HLS방식을 사용하게 되면 1개의 영상을 보더라도 적으면 50에서 많으면 100번 정도의 통신이 발생하는데 이 100번의 통계가 모두 사용량에 집계되어서 유저가 늘어나면서 기하급수적으로 증가하는 문제였었다.

• 물론 CDN을 사용해서 캐싱을 적용해서 HLS방식을 사용중이였지만 영상의 캐싱 기간을 하루로 설정한 상태였는데 영상과 오디오들이 수백개가 넘어가다보니 캐싱되어있는 미디어들의 경우엔 문제가 되지 않았지만 그렇지 않은것들도 많고 유저들이 많이 다양한 미디어 서비스들을 시청하고 듣고 보기 때문에 매일매일 수천수만번의 사용량이 집계되었다.

• 사실 이부분은 브라우저에서 직접 HLS로 비디오를 보여주면 이게 사용량에 잡히는 문제가있을 이유가 있나 라는 생각이 있었지만 Vercel의 아키텍쳐가 기본적으로 EKS로 감싸져 있는 형태인데 이런 모든 통신 하나하나가 해당 EKS를 무조건 거쳐서 들어오기 때문에 집계에 어떻게든 잡히게 되어있는 문제가 있었다.

Vercel로의 문의와 답변...

• 위 문제로 인해서 Vercel측의 도움을 받고자 문의를 남겼었는데(진짜 너무 늦게 답변해준다...ㅠ), 결국 받았던 답변은 미디어 파일의 용량을 줄이거나 캐싱 기간을 엄청 많이 늘리는 방식외에는 현재로선 해결할 방법이 없을것 같다는 답변을 받았다.

• 사실 뭔가 Vercel측에서 이러한 문제의 간단한 해결법이 있을거란 기대를 조금은 했었는데 생각외로 당연한 답변들만 받아서 결국은 AWS로 다시 이사가는것을 선택하게 되었다.

AWS로 다시 이사가기

• 기존에 메인 서비스 외에는 Amplify로 배포했었고 메인 서비스의 경우엔 ECS로 배포를 했었는데 ECS 배포의 경우엔 Amplify보다 배포가 느리기도하고 추가적으로 CI/CD부터해서 여러가지 설정을 직접해야하는 공수가 들기 때문에 이번에는 메인 서비스를 포함해서 전체적으로 Amplify로 이사가기로 결정했다.

• 우선 AWS로 이사가는 엄청큰 이유중 하나는 현재 AWS 서비스를 위해 메가존클라우드라는 회사와 최근에 계약하면서 여러 할인과 혜택들을 받고 인프라 비용을 많이 감소시키고 있는 중인데 여기서 프론트엔드쪽도 바로 문의를 넣어보면서 지원을 받을수도 있을것 같아서 옮기게된 이유가 컸었다. 추가적으로 Amplify로 배포한 서비스와 내부 CDN간의 데이터 전송비용이 더 저렴하다고 알고있어서 비용절감적인 부분에서도 이득을 볼 수 있을것 같아서 선택하기도 했다. 물론 서비스 사용방법도 매우쉽고 이미 다 할줄아는 상태이기도해서 이사가지 않을 이유가 없었다.

• 물론 Amplify로 이사갔을때 어느정도의 비용 절감과 이득을 볼 수 있을지는 구체적으로 예측은 되지 않지만, 일단 내부 모든 서비스들을 AWS상에서 관리할 수 있는것도 더 좋을것 같기도하고 도움을 받기도 쉽기 때문에 우선 1달간 지켜볼 예정이다. 그래서 1달간 어느정도의 차이가 생기는지 지켜보고 따로 정리해놓도록 해야될 것 같다. 가능하다면 해당 글에 업데이트해놓거나 추가글을 작성해보도록 하겠다!

• 논외로 다시 늘어난 빌드타임 시간이 좀 두렵기는한데 이 부분은 문의를 넣어보고 개인적으로 빌드시간과 배포시간을 감소시킬수 있는 방안을 찾아서 적용시킬 예정이다. 이 부분도 실제 해결하게 된다면 추가로 다른글로 작성해보는 시간을 가지면 좋을것 같다. :)